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(54) Bus and/or interface local capture module for diagnostic analyser 



(57) A localised bus and/or interface condition cap- 
ture module (26, 26) is incorporated at the interface (24, 
34) of a bus (21) with a peripheral device (22.32), for 
example embedded in an interface ASIC (41 ), discretely 
to track locally bus and/or interface signal condition, and 



the operational state or phase of an associated periph- 
eral device, for subsequent access, remote analysis 
and diagnosis. 
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Description 

[0001] For coherent and consistent operation, a 
data and command bus between otherwise disparate or 
independent remote elements - required to interact 
through exchange of data, interrogation and command 
or instructions - generally follows a prescribed behav- 
iour pattern or protocol. 

Protocol 

[0002] The term 'protocol' is used herein to 
embrace a regime, or rule set, for regulating - in relation 
to communications traffic over a data highway or path- 
way - the nature of interconnection or interface, the 
manner of interaction, and the content of information, 
interrogation or command, in data exchange or transfer 
elements or modules. 

[0003] A protocol can adopt and prescribe various 
operational rules and standards - to which ail physical 
connections with, and modes of communications over, 
the highway must defer, conform and adhere. 
[0004] Thus, so-called SCSI and PCI. represent 
examples of common contemporary protocols for (par- 
allel) bus configuration. 

Bus 

[0005] The term 'bus' is used herein to embrace any 
form of communications channel, data highway or path- 
way, particularly, but not exclusively, of a parallel, or mul- 
tiple simultaneous, channel or line character or 
configuration. 

[0006] That said, aspects of the invention may be 
applicable to other, for example serial, bus configura- 
tions. 

[0007] Generally, a bus is a transmission line, com- 
monly expressed or embodied as a hardware signal 
path, of physical conductors, whether (umbilical) cables 
or printed circuit board (PCB) conductor strips. 
[0008] As such, a bus could find diverse application 
from, say. vehicle electrical supply engine, transmission 
and brake monitoring and command multiplex wiring 
harness, through to personal computers. 
[0009] Hardware aside, a bus could be interrupted - 
or even part-constituted by - intermediate radio, optical 
fibre or infra-red links, provided an electrical signal can 
physically be picked up at some point (eg of bus termi- 
nation). 

Interface 

[0010] interaction between a bus, a primary com- 
mand and control processor or central processing unit 
(CPU) and a (peripheral) device is through an interface 
- which itself must adhere to the bus protocol, but which 
enables physical (impedance or load) matching of oth- 
erwise incompatible elements, to allow converse there- 



between. 

[0011] The term 'interface' is used herein to 
embrace an interconnection, principally by physical 
interaction, with a bus. 

5 

(Interface) ASIC 

[0012] It is common to use a dedicated or bespoke 
(semiconductor) device configuration, such as an ASIC 

w (Application Specific Integrated Circuit), in an interface 
between a bus and a peripheral device. 
[0013] Such a 'dedicated' ASIC is then instrumental 
in controlling interactions between a peripheral and the 
bus - and, in particular, (when the protocol so allows) in 

15 a peripheral 'asserting" and 'de-asserting' temporary 
control over the bus, as discussed later. 
[0014] Some aspects of the present invention are 
concerned with supplementing, enhancing or reinforc- 
ing the use of such an interface ASIC, with additional 

20 functionality and memory, intimately to address local 
conditions: 

at the driver output of the ASIC; and 
input of the ASIC. 

25 

Bus or Interface Protocol 

[0015] A bus or interface protocol commonly 
embraces various features of hardware and software. 

30 As such, a protocol may dictate or prescribe signal lev- 
els, or ranges, and allocate particular significance to 
certain signal sequences, or combinations. 
[0016] According to bus or interface configuration, 
the protocol may also allocate particular (control) func- 

35 tions to certain individual signal lines or channels, or 
select multi-channel combinations. 
[0017] Generally, a given bus protocol prescribes 
intended or envisaged 'allowable', or correct, bus 
instantaneous signal level conditions, on individual bus 

■io lines. 

[0018] However, the protocol may not be overly 
specific upon allowable departures from recommended 
or set levels - and so upon what would constitute an 
'error' or fault condition, (and as such one in need of cor- 
45 rection or resolution), as discussed later. 

[0019] A protocol may also define signal level tran- 
sitions, or changes, and sequences. Regard might also 
be paid to the cumulative or combinatorial effect of sig- 
nal levels. 

so [0020] Some, but not all, protocols may allow differ- 
ent peripheral devices temporarily to take command 
and control over, or to 'assert* the bus. 
[002.1] Should an error or fault condition arise, as 
described later, it is important to know (in a bus which 

55 so allows) which (peripheral) device is asserting the bus 
at the time, in order to pin-point the source of 'deviant' 
behaviour. 

[0022] Some form of local error monitoring capabil- 
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ity - as provided by aspects of the present invention, dis- 
cussed later - is particularly advantageous when the 
protocol allows such peripheral device assertion. 
[0023] Interrupt signals on the bus could preface 
hand-over and hand-back signal sequences, passing 5 
the bus over to other peripheral devices, or back to a 
centralised command CPU. Indeed in practice, in a 
computer system, the peripheral device(s) might well 
occupy more time cumulatively in charge of the bus than 
the CPU itself. w 
[0024] Hence the value of knowing which device is 
actively 'asserting' and which device(s) are 'passive' at 
any sampling instant. When not asserting the bus. a 
peripheral device is free to receive signals from, or to 
interrogate, signals upon the bus. ? 5 
[0025] Generally, a device state will reflect signals 
detected on the bus. through an associated device inter- 
face. 

[0026] In considering the interaction between a 
peripheral and the bus. separate or individual consider- 20 
ation must be given to: 

the outflow of signal directives - in a bus 'assertion' 
or driving mode; and 

the inflow of signals from the bus - in a passive 25 
reception or driven mode. 

[0027] The passive mode is significant, since the 
peripheral can be commanded to change operational 
state or condition, in response to perceived bus signal 30 
changes. 

[0028] Missed, or wrongly interpreted, bus signals 
can lead to a missed or skipped device state change 
and consequent disruption of device operational 
sequence in synchronism with the bus - and attendant 35 
degradation in peripheral performance. 
[0029] Physically, there is a unique common point 
or node location, from or at which both outgoing and 
incoming signals may be encountered - for analysis of 
bus interactions and bus read-write errors associated <*o 
with that peripheral. 

[0030] A conventional self-contained bus analyser 
connected at a remote location (from the peripheral and 
its associated interface), simply cannot address or map 
that critical interface input-output node, which will enjoy J5 
an unique signal level profile. 

[0031] Nor can a conventional bus analyser deter- 
mine directly the operational state or phase of individual 
peripheral devices. 

[0032] Thus bus signal condition - upon which a 50 
conventional bus analyser is critically dependent - is not 
uniform throughout the bus. Nor is bus signal condition 
necessarily indicative, either of local interface signal 
condition (for any given peripheral), or of the operational 
state of that peripheral. 55 
[0033] The diagnostic ability of a conventional bus 
analyser is thus constrained - and inadequate for a 
complete diagnostic role. 



[0034] Moreover, since a bus is effectively a trans- 
mission line, with inherent (characteristic) impedance 
losses throughout, it follows that relative 'downstream' 
or upstream' bus tappings cannot replicate a localised 
approach - as envisaged with aspects of the present 
invention. Nor can a remote bus analyser recognise 
state changes of individual peripherals. 
[0035] Thus part of the performance - and thus 
error - mapping is incomplete, and so potentially inade- 
quate, in the conventional remote error signal capture 
and diagnostic approach. 

[0036] As a transmission line, the bus access inter- 
faces and terminations can prove critical. Thus bus 
loads must be matched to the bus transmission line 
characteristics, for effective signal energy transfer. Mis- 
matching can lead to spurious signal reflections or ech- 
oes and attendant interpretation errors and disruption. 
Matching an external bus analyser to a bus can be prob- 
lematic. 

[0037] The character or nature and extremity or 
degree of errors that can be tolerated by a bus protocol 
is not generally well-specified. Not all protocol interpre- 
tations by peripherals, or indeed the bus construction or 
CPU themselves, are uniformly consistent or 'robust*. 
[0038] It can be difficult to determine which errors 
will lead to total and non-recoverable bus failure and 
which to continual minor disruption, such as might trig- 
ger repeated automatic bus condition resets. Whilst a 
certain fault-tolerance can be built into the protocol, a 
tight or well-specified protocol may generally be less tol- 
erant to errors or deviations from standard. 
[0039] Deference to and compliance with protocol 
is a pre-requisite of stable performance. That said, 
departure or deviation from the protocol, however aris- 
ing, disrupts data transfer and impedes performance of 
peripheral devices. Yet such irregularity can be difficult 
to identify. Moreover, with multiple inter-connected 
devices, the location of faults can be difficult to pin- 
point. 

[0040] An interface standard, such as SCSI, 
requires a recognition of the current phase of the oper- 
ational protocol and a knowledge of how to (re-)act 
accordingly, from current bus signals. 
[0041] With multiple peripheral devices, (inter) con- 
nected through a common bus. differences in interpre- 
tation of the (say, SCSI) bus or interface protocol 
specification and consequently implementation of deci- 
sion logic can cause problems. 

[0042] Software aside, hardware problems can also 
arise from essentially physical factors, such as sporadic 
•glitches*, unsatisfactory terminations or location of 
peripherals - any of which can affect the perception of 
bus signals. 

[0043] Testing and de-bugging tools, such as pro- 
prietary self-contained (SCSI) bus (interface) analysers, 
are typically employed to review system performance 
from 'silicon turn-on", through functional or product test- 
ing, to overall system integration. 
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[0044] In principle, by connection to the bus. such 
an analyser should act as a 'passive' observer, to cap- 
ture information upon signal edge change or level tran- 
sition and as such is useful in low level hardware and 
chip de-bugging. 

[0045] However, protocol errors may well arise out- 
side bus analyser testing. If the error has not been cap- 
tured, it may at best be time-consuming to reproduce, or 
at worst non-repeatable. 

[0046] Moreover, the very presence of the analyser 
on a bus can materially alter its physical characteristics 
- potentially to the extent that an error problem may no 
logger be .perceived. Yet that error condition may re- 
occur when the analyser is disconnected. 
[0047] Indeed, it may prove difficult even to attach 
an analyser to a bus, without violating prescribed physi- 
cal bus or (bus/interface offshoot or branch) stub length 
maxima. 

[0048] Certain bus signal lines, such as those des- 
ignated 4 8SY' or 'SEL', may be asserted by any periph- 
eral following normal protocol - so the analyser cannot 
determine which peripheral is asserting bus signals in a 
fault condition. 

[0049] Indeed, bus signal values perceived by an 
analyser on test mode reflect its (different) bus position- 
ing - and so may not equate to that observed and inter- 
preted by a (suspect) device. 

[0050] Similarly, problems may arise on (customer) 
site, remote from diagnostic tools or expertise - and 
again it may not be possible to re-create them - with 
attendant customer dissatisfaction. 
[0051] Thus, fault correction requires careful moni- 
toring, analysis and interpretation. Errors can arise 
attendant physical device or inter-connection distur- 
bances and mis-tracking of signal sequences, which 
can be independent or related. 

[0052] SCSI is a particular example of a highly spe- 
cific interface and bus protocol. SCSI configured periph- 
eral devices include internal or external (in relation to a 
computer) hard disks, tape drives, CD-ROMS, printers, 
scanners etc. 

Statement of Invention 

[0053] According to one aspect of the invention, 

a bus and/or interface condition capture module. 

for integration or embedding in an interface 

between a command and data bus, 

such as a SCSI bus. 

and a computer peripheral device, 

is configured to serve as part of a bus analyser. 

the module comprising 

discrete memories for temporary storage of bus 
and/or interface signal condition 
and operational state or phase of the peripheral, 
for subsequent access, remote analysis and diag- 
nosis. 



[0054] The term analysis embraces interpretation 
and appraisal. 

[0055] The memories may be configured as. say. 
RAM, or FIFO, with read-write modes adjusted accord- 
5 ingly. 

[0056] The data captured includes both: 

'correct', (protocol) conforming or compliant; and 
'incorrect'. non(protocol)-conforming. non-compii- 
10 ant, ie error or fault. 

signal conditions and/or operational states. 
[0057] Such a capture module is conveniently incor- 
porated in, or as an adjunct to, an interface ASIC, of a 
75 computer peripheral device, and configured to capture 
local bus and/or interface signal condition and opera- 
tional state of the peripheral, for subsequent access, 
remote analysis and diagnosis. 

[0058] In practice, the capture module could include 
20 a memory structured to store a history of bus signal 
transitions, and the assertion or de-assertion of signals, 
by the associated peripheral device, in whose interface 
the module is incorporated. 

[0059] The invention embraces a peripheral device, 
25 with a bus interface incorporating a capture module. 
[0060] The invention also embraces a computer, 
connected, through a bus, and peripheral interface, to a 
peripheral device, incorporating a bus and/or interface 
condition capture module. 
30 [0061] According to yet another aspect of the inven- 
tion. 

a method of bus and/or interface condition capture 

comprises the steps of 
35 separately monitoring criteria of 

bus and/or interface signal condition 

and operational state or phase 

of an associated peripheral device, 

and storing discretely 
40 changes in those criteria, 

for subsequent access, 

remote analysis and diagnosis. 

[0062] According to a further aspect of the inven- 
45 tion, 

a bespoke or dedicated bus and/or interface ASIC, 
is configured to incorporate, or work alongside, 
a localised bus and/or interface condition capture 
50 module, 

with discrete working memories, 
respectively for 

bus and/or interface signal condition 
and operational state or phase.of an attendant 
55 peripheral device. 

for onward relay to larger, longer terms storage, 
ready for subsequent access, remote analysis and 
diagnosis. 
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[0063] Soth 'correct' or 'incorrect' signal levels or 
conditions and related or consequential peripheral oper- 
ational states or phases could ce recorded, continually 
- subject to occasional 'flushing' into a local RAM. under 
localised interface (eg ASIC) firmware control, ready for 5 
remote downloading or off-loading through bus ports, 
for devolved analysis and diagnosis. 
[0064] If the peripheral is itself, or embodies, a large 
working memory, a portion could be allocated to the 
longer term (pre-diagnosis) retention of bus and/or w 
interface condition and peripheral state. 
[0065] It is envisaged that localisation - at a unique 
peripheral to bus interface - of such a capture module 
would provide a more detailed and intimate record of 
interface conditions and associated peripheral state, is 
than available hitherto from conventional stand-alone 
bus analysers. 

[0066] In the short term, this facilitates diagnosis of 
machines away from a test laboratory, such as in cus- 
tomer hands. It would also allow the separation or isola- 20 
tion of error conditions arising from unique 
circumstances of customer environment or usage - 
such as power supply spikes. In the longer term, the 
error log should assist in 'designing-out' conditions lead- 
ing to errors, or achieving greater resilience to error con- 25 
ditions. such as spurious noise. 

[0067] In practice, the capture module could be 
implemented within, or alongside, an existing bespoke 
interface ASIC, with minimal disturbance to existing 
•functionality. Nevertheless, the potential benefits could 20 
be (favourably) out of all proportion to the relatively 
modest implementation 'overhead' penalty. 
[0068] The capture section or module records both 
bus signal levels drive signals initiated by the interface 
ASIC. The capture module memory required is rela- 35 
tively modest, as it is continually flushed - say. to a 
remote store, for analysis - and refreshed with more cur- 
rent bus condition data. 

[0069] In one variant, the capture module memory 

is conveniently configured to a FIFO (first in - first out) ^0 

operational store inventory mode. 

[0070] Overall, the capture module effectively func- 
tions as a localised capture section of a 'focussed* bus 
analyser. 

[0071] Capture operation is conveniently under J5 
control of firmware, which could detect occurrence of 
protocol error or bus/device reset - whereupon the bus 
condition data could be read into local processor mem- 
ory, for subsequent remote extraction, over the bus 
itself, or through a bespoke diagnostic port or emulator 50 
interface. 

[0072] Localisation of protocol error condition cap- 
ture - through an interface ASIC - obviates reliance 
upon failure mode repetition under contrived test condi- 
tions. 55 
[0073] Absent this, full spectrum functional testing 
would otherwise entail a host of expensive analysers, in 
turn reliant upon statistical probabilities to catch failures 



for analysis. 

[0074] With a peripheral device at a remote cus- 
tomer site, fault data from on-board capture modules 
can be downloaded electronically, using a software util- 
ity, to a diagnostic base. Without failure mode repetition, 
de-bugging is more readily undertaken. 
[0075] The capture module stores a history of bus 
signal transitions, along with assertion/de-assertion 
instances by the associated peripheral. This in turn 
facilitates isolation of peripherals generating protocol 
errors, and attendant de-bugging. 

[0076] More particularly, the local capture module 
records 'actuality of perception and reaction' of the 
peripheral device under scrutiny - rather than a value 
perceived at a different bus position. 

Embodiments 

[0077] There now follows a description of some par- 
ticular embodiments of bus and/or interface capture 
modules according to the invention, by way of example 
only, with reference to the accompanying diagrammatic 
and schematic drawings. 

[0078] These drawings reflect aspects of circuitry 
configuration and organisational logic layout and 
sequence, and in which: 

Figure 1 shows a general layout of a (SCSI) bus 
supporting multiple peripheral devices, each with 
localised bus and/or interface capture modules 
incorporated in a respective peripheral interface 
ASIC; 

Figure 2 shows a peripheral-to-bus interface detail 
of the Figure 1 layout; 

Figure 3 shows a condensation of localised bus sig- 
nal condition capture on certain individual bus lines; 
Figure 4A shows dual peripheral driving and pas- 
sive driven mode localised bus and/or interface sig- 
nal condition signal capture; 

Figure 4B shows a generalised bus analyser 
scheme; 

Figure 5 shows firmware control of bus and/or inter- 
face signal condition and peripheral operational 
state capture and temporary storage: 
Figure 6 shows a more developed scheme for bus 
and/or interface signal condition and operational 
state capture; 

Figure 7A and 7B show capture module (RAM) 
memory address configurations, respectively for 
discrete storage of bus and/or interface signal con- 
dition and peripheral operational state or phase 
vector; 

Figures 8A through 8E chart operational stages of 
the memory configurations of Figures 7A and 7B. 

[0079] Referring to the drawings, a bus 21 - in this 
case configured to a SCSI protocol - supports various 
peripheral devices 22, 32, connected to the bus 21 
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through respective local interfaces 24. 34. For com- 
pleteness, the bus is depicted with a matched end ter- 
mination 28. There may also be provision (not shown) 
for supplementary peripheral device interconnection 
[0080] The bus 21 is driven by a centralised com- 5 
mand processor or CPU 12, through a respective local 
interface .14. The peripheral interfaces 24. 34 incorpo- 
rate dedicated or bespoke configured ASIC semicon- 
ductor devices. 

[0081] The interface ASIC's incorporate, or are sup- w 
plemented by, local bus and/or interface (condition) cap- 
ture modules (26, 36). These capture modules (26, 36), 
preface or represent initial or prefacing stages of what 
are effectively local bus and/or interface analysers - 
even though an analytical or diagnostic facility need not 15 
itself be localised. 

[0082] . In principle, the extent of "local intelligence' 
under firmware control admits of some variation - from 
raw data capture through to some screening or discrim- 
ination upon data capture and even preliminary inter- 20 
pretation. towards a more focussed or purposeful 
analysis and diagnosis. 

[0083] The CPU 12 interface 14 is also depicted 
with a dedicated ASIC and associated capture module 
16. As shown in Figure 2. a dedicated peripheral inter- 25 
face ASIC 41, addresses the bus 21 through a nominal 
link 42, anc is configured with a localised capture mod- 
ule 43. The capture module 43 is effectively part of a 
local bus analyser. 

[0084] Such capture has a dual capability, not avail- 30 
able in the conventional bus analyser approach, 
namely: 

local bus and/or interface signal condition; and 
peripheral operational state or phase. 35 

[0085] More particularly, the bus and/or interface 
signal condition is available in both read (driven) or write 
(driving) modes - that is when the peripheral is passive 
on the bus. or when the interface has 'asserted' or taken 40 
command over, and is temporarily driving the bus. 
[0086] Intimate local knowledge can thereby be 
gained of which peripheral is asserting the bus when an 
error or fault arises - and which can be critical to diagno- 
sis. This is more difficult to achieve remotely, as in a 45 
conventional bus analyser. 

[0087] Duality of capture is effected through supple- 
mentary discrete memories 51 , 52 integrated or embed- 
ded in, or as a supplement or adjunct to, the interface 
ASIC 41 - and configured respectively for separate stor- so 
age of bus and/or interface signal condition and periph- 
eral operational state. In practice, the memories 51, 52 
could be FIFO's, rather than RAM. 
[0088] More particularly, a continual or selective 
record can be kept through the memories 51 , 52 of sue- 55 
cessive changes in bus and/or interface signal condition 
and the operational phase of the associated peripheral 
24. 34. This is achieved through repeated clock cycle 



writing. 

[0089] Thus, in one operational variant, the memo- 
ries 51. 52 are selectively addressable through a mem- 
ory address pointer 49. The memory address pointer 49 
is 'incremented* (ie moved or indexed to load a follow-on 
memory address) by a counter 48, which may in turn be 
placed under control of firmware 50. 
[0090] Periodically, the firmware 50 can direct that 
the memories 51. 52 be 'flushed' into larger, longer 
term, remote storage, such as processor RAM 61. Alter- 
natively, inherently larger capacity RAM configured 
memory could be loaded direct. 

[0091] The localisation of bus and/or interface sig- 
nal condition capture can pay special regard to certain 
critical bus lines. Figure 3 shows the localised bus 
and/or interface monitoring and signal condition capture 
of certain 'SEL' and *BSY' bus lines, 63, 65 - through 
respective input/output sections 66, 67 in the interface 
ASIC 41, under control of firmware 50. 
[0092] Clock pulse signals 69 to the firmware 50 
from a timer 68 can orchestrate stepping through an 
operational sequence. The contents of discrete stores 
51, 52 could be flushed periodically, through a transfer 
line 64. to a remote, temporary SRAM 61. 
[0093] Figure 4A reflects bus and/or interface 21 
interrogation or monitoring, for continual signal condi- 
tion capture, through an input stage 71 and output or 
driver stage 72. with a common nodal connection to the 
bus link 42. 

[0094] Figure 4B reflects a bus analyser 74 examin- 
ing both signal condition from an input stage 73 and the 
state of operational logic 75. 

[0095] Figure 5 represents firmware 50 diverting 
successive interface ASIC 41 bus and/or interface sig- 
nal conditions, to address locations 91. 92 in memories 

51, 52. in accordance with comparative trigger criteria 
76, paying attention to previous conditions. 

[0096] Figure 6 shows a more - developed bus 
and/or interface scheme in which a bus 21 instructs the 
operational state or phase of a peripheral engine 98. 
[0097] Provision is made for hosting the 'normal' 
peripheral interfaces and attendant logic (not shown). 
[0098] Current bus and/or interface signal condition 
is held in a (bus) register 102, for comparison, through a 
comparator 103, with a previous bus and/or interface 
signal condition held in another bus register 101. 
[0099] Any condition change is loaded into a mem- 
ory 51. configured as described in relation to Figure 7A. 
Similarly, current peripheral operational state or phase 
is loaded into a state register 116. 
[0100] A comparator 115 compares the current 
peripheral state with a previous state, held in another 
state register 1 14. Any change is fed to a state memory 

52. whose configuration is described in relation to Fig- 
ure 7B. 

[0101] Referring to Figures 7A and 7B, adoption of 
separate storage 51, 52 respectively for bus and/or 
interface signal condition and peripheral operational 
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state or phase reduces the overall memory size require- 
ment, since each change in bus signals would other- 
wise also use an attendant state" store location. That is 
a peripheral operational state or phase change does not 
necessarily accompany every bus and/or interface sig- 
nal condition change. 

[0102] Whilst the memories 51, 52 operate inde- 
pendently, their operation is similar. Thus, the following 
description of operation of memory 51 is relevant to that 
of memory 52. 

[0103] At the start of a monitoring sequence, a 
reset signal sets a counter 48 and RAM address pointer 
49 to zero, with the analyser configuration set to ana- 
lyser operating mode. The initial state of the (SCSI) bus 
is then written to the allocated RAM module 51. using 
the first address block 91. whereupon the address 
pointer 49 is incremented. 

[0104] Every sampling period - for example a clock 
cycle - the (SCSI) bus lines are compared with the ini- 
tially stored value and the counter 48 incremented. 
Should a difference arise between the new current 
value and the previous stored value, this new value is 
stored in the RAM 51 . along with the value of the coun- 
ter 48 at that instant. The counter 48 is then reset and 
the address pointer 49 incremented. 
[0105] The bus line condition monitoring is a contin- 
uous operation, with the RAM location addresses 91 . 92 
etc. adopted successively in circulation, around the size 
of the FIFO storage mode - progressively, or incremen- 
tally over-writing the oldest data, so that the latest 
change(s) will always be available. 
[0106] The analysis operation is halted to allow 
data reading from the memory contents. This in turn 
inhibits ongoing comparison and further writing to the 
RAM 61. The address pointer 49 is read to determine 
which address would have been used on the next write 
operation. Thus the oldest data is stored at that address 
and the firmware can read from the FIFO storage mode 
ail entries form that point onwards, taking into account 
the (address) 'wrap around'. 

[0107] This information is stored in processor RAM 
61. ready for later extraction via. say, the (SCSI) bus 
itself, a diagnostic port, or emulation tools. Once stored 
the firmware can reset the analyser operation, without 
needing to reset the RAM address to a specific value 
before restarting. This operational mode is only needed 
with a RAM implementation of the memory. 
[0108] Generally, with a FIFO (as opposed to. say, a 
RAM) implementation of memory, storage is halted 
while values are read out, one after another, from the 
same memory address. Upon each occasion data is 
loaded, the memory stack shuffles down, 'loosing' the 
oldest data as it 'drops off the stack capacity. 
[0109] Similarly, as data is read from the 'top* of the 
FIFO stack, so an 'upwards* re-shuffling of data takes 
place. Thus, in the absence of a read out, the progres- 
sively oldest data is lost. Either implementation is feasi- 
ble, or indeed a combination of the two. 



[0110] The entire memory address block is not 
reset by the (SCSI) bus reset, although hardware and 
software resets will be effective. This is crucial opera- 
tionally . The peripheral operational state or phase vec- 
5 tor memory capture module 52 operates in a 
corresponding manner. 

Component List 



io [0111] 

12 CPU 

14 CPU interface ASIC 

16 CPU interface ASIC capture module 

is 21 (SCSI) bus 

22 peripheral 

24 peripheral bus and/or interface ASIC 

2 6 peripheral bus and/or interface ASIC capture 
module 

20 28 terminator 

32 peripheral 

34 peripheral bus and/or interface ASIC 

36 peripheral bus and/or interface ASIC capture 
module 

25 41 peripheral bus and/or interface ASIC 

42 nominal bus and/or interface link 

43 localised bus and/or interface capture module 

48 counter 

49 address pointer 
30 50 firmware 

51 memory - bus signal condition 

52 memory - peripheral state 
61 processor RAM 

63 bus signal line 'SEL' 

35 64 memory transfer 

65 bus signal line 'BSY' 

66 input/output device 

67 input/output device 

68 timer 

40 69 timing pulse 

71 input 

72 output driver 

73 input 

74 bus analyser 

45 75 operational logic 

76 trigger 

91 memory address 

92 memory address 
98 operational engine 

so 101 bus condition register 

102 bus condition register 

103 bus condition comparator 

1 14 operational state register 

1 1 5 operational state comparator 
55 116 operational register 
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Claims 

1. A capture module, 

for integration with, or embedding in. an inter- 5 
face, 

between a command and data bus. 

conforming to a prescribed protocol. 

and a computer peripheral device, 

the capture module being configured 10 

to serve as part of a bus analyser. 

and comprising 

discrete memories for temporary storage 

of bus and/or interface signal condition 

and operational state or phase of the periph- 15 

eral, 

for subsequent access, remote analysis and 
diagnosis. 

2. A capture module. 20 

as claimed in Claim 1 , 

incorporated in. or as an adjunct to. 

an Application Specific Integrated Circuit 

(ASIC), 25 

in the interface of a computer peripheral 

device, 

and configured to capture local bus and/or 
interface signal condition 

and operational state of the peripheral, 30 
for subsequent access, remote analysis and 
diagnosis. 

3. A capture module. 

35 

as claimed in either of the preceding claims, 
including a memory, 

structured to store a history of bus signal tran- 
sitions, 

and the assertion or de-assertion of signals, 40 

by the associated peripheral device, 

in whose interface the module is incorporated. 

4. A peripheral device, 

45 

with a bus interface incorporating a capture 
module, 

as claimed in any of the preceding claims. 

5. A computer. so 

connected, through a bus, 

and peripheral interface, 

to a peripheral device as claimed in Claim 4. 

55 

6. A method of bus and/or interface condition capture. 

for analysing bus protocol conformity, 



and comprising the steps of 

separately monitoring criteria of 

bus and/or interface signal condition 

and operational state or phase 

of an associated peripheral device. 

and storing discretely 

changes in those criteria. 

for subsequent access, remote analysis and 

diagnosis. 

7. A bespoke or dedicated interface ASIC. 

configured to incorporate, or work alongside, 
a localised bus and/or interface condition cap- 
ture module, 

with discrete working memories, 
respectively for 

bus and/or interface signal condition and 
operational state or phase of an attendant 
peripheral device 

for onward relay to larger, longer terms storage, 
ready for subsequent access, remote analysis 
and diagnosis. 
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43 

Capture Module for local (SCSI) Bus Analyser 
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Figure 3 
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